Set GOMAXPROCS automatically #41
Conversation
|
isnt there a threadiness for kubebuilder too? i forget out it works or is set but maybe we need to worry about that too? this is fine to merge as is tho imho |
Please let me know if there is a better way. We don't have to worries too much about this, but setting the right number of CPUs overall makes sense. |
So you can set the MaxConcurrentReconciles (defaults to 1) that controls how many go routines get created on the controller. I don't think we have to do adjust that as part of this PR but I think it's good to note that it's currently defaulting to 1 and we'd probably want to revisit that. |
Co-authored-by: Richard Kovacs <[email protected]>
When the Go runtime starts it creates an OS thread for each CPU core. This means if you have a 16 core machine the Go runtime will create 16 OS threads - regardless of any CGroup CPU Limits. The Go runtime then uses these OS threads to schedule goroutines.
The problem is that the Go runtime is not aware of the CGroup CPU limits and will happily schedule goroutines on all 16 OS threads. This means that the Go runtime will expect to be able to use 16 seconds of CPU time every second.
Long stop the world durations arise from the Go runtime needing to stop Goroutine on threads that it’s waiting for the Linux Scheduler to schedule. These threads will not be scheduled once the container has used it’s CPU quota.
For more info please follow: https://www.riverphillips.dev/blog/go-cfs